home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / smtpext / smtpext-minutes-92mar.txt < prev    next >
Text File  |  1993-02-17  |  7KB  |  131 lines
  1. This is only a rough draft - Megan 04/15/92
  2.  
  3. IETF SMTP Extensions WG
  4. Minutes: San Diego IETF
  5. --------------------------
  6.  
  7. Summary
  8. -------
  9.  
  10. During the San Diego meeting, the WG reviewed several issues that had been
  11. settled earlier, but for which it appeared that new technical issues had
  12. been identified.  The WG concluded that there were, in fact, no
  13. significant new technical issues being raised, and no significant changes
  14. to the working document were made.  The WG did succeed in tying up the
  15. remaining loose ends in the document, including identifying locations
  16. where additional explanatory text was needed and providing exact keywords,
  17. syntax, and definition for concepts agreed upon some time ago.
  18.  
  19. The present draft provides an extension model and compatible
  20. extensions to SMTP for mail transport of 8-bit characters.  Using the
  21. same extension model, it provides some additional extensions to
  22. supplement SMTP and improve its efficiency, especially when very
  23. large files are being transmitted.
  24.  
  25. It is expected that a new Internet Draft, reflecting agreements made in
  26. San Diego, will be produced shortly after IETF, reviewed quickly on the
  27. mailing list, and then submitted for processing as a proposed standard.
  28.  
  29. The meeting contained an extended discussion of the issues raised the
  30. previous day, including a review of whether the WG's work and the RFC-ZZZZ
  31. model fit well into a "transition plan"/"final target" model.  Several
  32. other issues were revisited, including the question of whether we might be
  33. better off with a new protocol on a new port.  The assertion was made that
  34. the present model either constituted two separate services over the same
  35. port (in which case it was muddled and wrong) or some attempt at hidden
  36. gateways (in which case there was fear of other problems).  It was pointed
  37. out that the two port model made it very difficult to distinguish between
  38. no service on the "new" port and temporary unavailability.  The advocates
  39. of the two-port model felt that this was a non-problem unless one wanted
  40. to mix services or have implied gateways.  It was pointed out that no
  41. gateway was implied if the originating system was prepared to send a
  42. message in either 8-bit or 7-bit form, but preferred 8 if that was
  43. available.   There was a brief religious argument as to whether or not
  44. this case was interesting.
  45.  
  46. The WG concluded that it did not want to revisit the "new port" issue.
  47.  
  48. A second heated discussion over the CPBL command with a contention that
  49. the command would increase the number of round trips pitted against a
  50. contention that it would give intelligent clients the ability to reduce
  51. the actual number of round trips.  The WG decided to retain CPBL.
  52.  
  53. The issue of "SIZE" was reviewed, both with regard to the information to
  54. be returned by CPBL (redesignated as "LIMIT" after the meeting to reduce
  55. possible confusion) and with regard to the estimation and treatment of the
  56. value to be sent with the SIZE verb.  The WG concluded that the capability
  57. limit should be reported in terms of two administrative values, the size
  58. that the implementation would try to provide in all cases and the size
  59. that would probably always be rejected.  The editor was directed to
  60. provide some guidance in the document for estimating, in hosts with
  61. single-character newline conventions internally, the size to be
  62. transmitted.  See the new version of the draft document for the results of
  63. these discussions.
  64.  
  65.  
  66. Details of Discussions and Decisions
  67. ------- -- ----------- --- ---------
  68.  
  69. As discussed in the summary above, much of the two WG sessions at this
  70. meeting was devoted to a review of previously-settled issues, sometimes
  71. from a new point of view.
  72.  
  73. Issues and proposals raised included:
  74.  
  75. * Syntax and semantics for the response to the CBPL command/inquiry. 
  76.    The WG decided that this should list all capabilities of the server, on
  77.    a one-verb-per-line basis, using the existing syntax for multiline
  78.    responses.  This is one of the options considered in Santa Fe and
  79.    tentatively approved.  The handling of the "message size" portion of
  80.    the response was as agreed on in Santa Fe, i.e., providing the
  81.    administrative limits.
  82.  
  83. * Syntax and semantics of the SIZE command.
  84.    The decisions made in Santa Fe were affirmed and refined.
  85.  
  86.    See the forthcoming version of the Internet Draft for additional
  87. details on the two features above.
  88.  
  89. * Possible separation of a "transition model" from the "protocol" as it
  90. would exist in deployed form, e.g., creating two clearly separated
  91. documents. 
  92.    The WG concluded that this was neither necessary nor appropriate.
  93.  
  94. * Possible replacement of the notion of capabilities inquiries with a
  95. clear "version" model with no optional features.  The theory behind
  96. this was that the Internet has succeeded because of the small number of
  97. options (Telnet negotiation notwithstanding) and that few clients have
  98. really be designed to take advantage of optional features in any event.
  99. This discussion led to the insight that some confusion has been created
  100. by describing EMAL and related features in "negotiation" terms.  They
  101. are really verification that particular expected capabilities are
  102. present.
  103.    The next version of the Internet-Draft will been modified to reflect
  104.    the "verification" terminology and to remove "negotiation".  This does
  105.    not affect the operation of the proposed protocol.
  106.  
  107.    After some discussion, the WG concluded that a "version" model was
  108.    inappropriate.  Different members saw different problems, but the most
  109.    serious included the fact that SMTP already contains optional features
  110.    (e.g., the interactive mail commands SEND FROM, SOML FROM, and SAML
  111.    FROM) and that introducing strict "all or nothing at this level"
  112.    versioning would require either requiring support for those verbs and
  113.    concepts or deprecating them.  The WG was unwilling to consider doing
  114.    either; some members considered such tampering with the requirement
  115.    level for existing features to be outside the WG's scope.  There were
  116.    also concerns about excessively raising the level of effort required
  117.    for a minimal implementation of the new features, thereby defeating the
  118.    WG's goal of providing as smooth and easy a transition path to existing
  119.    (nonconforming) 8bit-sending implementations as possible.
  120.  
  121.  
  122. * There was interest expressed in "address streaming" and, in
  123. particular, return of sequence numbers in replies to RCPT TO commands.
  124.     The WG concluded that this was not an extension it was willing to make
  125.     to SMTP during the current round, especially since no concrete or
  126.     specific proposal was on the table.
  127.  
  128. John C. Klensin
  129. Chair
  130. IETF SMTP Extensions WG
  131.